Reading appsettings file using IConfiguration vs IOptions, Comparisons in ASP.NET Core

ASP.NET Core में IConfiguration बनाम IOptions

इस लेख में हम ASP.NET Core में IConfiguration बनाम IOptions का उपयोग करके appsettings फ़ाइल पढ़ने की तुलना करेंगे।

हम IConfirmation ऑब्जेक्ट को कंस्ट्रक्टर इंजेक्शन के माध्यम से किसी क्लास में इंजेक्ट करके appsettings file कॉन्फ़िगरेशन डाटा को पढ़ सकते हैं. प्रश्न है कि

• क्या IConfiguration को constructor injection के माध्यम से क्लास में inject करके config पढ़ लेना पर्याप्त नहीं है?
• और अगर हम ऐसा करते हैं, तो क्या हमें वही लाभ मिलते हैं जो IOptions<T> से मिलते हैं?

इसका उत्तर है:

• हां, IConfiguration को inject करके भी configuration पढ़ा जा सकता है,
• लेकिन यह IOptions<T> जितना structured, strongly-typed, scalable और flexible नहीं होता।

🔍 चलिए दोनों approaches को side-by-side तुलना करके समझते हैं:

Approach 1: IConfiguration injection

Setup:

public class EmailSender
{
    private readonly IConfiguration _configuration;
    public EmailSender(IConfiguration configuration)
    {
        _configuration = configuration;
    }
    public void SendEmail()
    {
        var host = _configuration["SmtpSettings:Host"];
        var user = _configuration["SmtpSettings:Username"];
    }
}

लाभ:

लाभ	विवरण
सरल	कोई binding class बनाने की जरूरत नहीं
हर key के लिए सीधा access	string-based access
Minimalist	छोटे apps या scripts में सरल

सीमाएँ:

समस्या	विवरण
No type safety	सब कुछ string से access करना पड़ता है
No IntelliSense / Autocomplete	सिर्फ hardcoded string keys
No validation support	required fields validate नहीं होते
Difficult to unit test	mock करना या override करना झंझटपूर्ण
Repeatable parsing	हर बार convert करना पड़ेगा (int.Parse etc.)

Approach 2: IOptions injection (Options Pattern)

Setup:

using Microsoft.Extensions.Options;
public class SmtpSettings
{
    public string Host { get; set; }
    public string Username { get; set; }
}
public class EmailSender
{
    private readonly SmtpSettings _smtp;
    public EmailSender(IOptions<SmtpSettings> options)
    {
        _smtp = options.Value;
    }
    public void SendEmail()
    {
        var host = _smtp.Host;
        // type-safe    
    }
}

लाभ:

लाभ	विवरण
Strongly typed	compile-time safety
IntelliSense सपोर्ट	developer productivity
Validation संभव	[Required], FluentValidation आदि
Test में आसानी	IOptions को mock करना सरल
Per-scope flexibility	IOptionsSnapshot / IOptionsMonitor उपलब्ध

सीमाएँ:

दोष	विवरण
थोड़ा boilerplate अधिक	POCO class बनानी होती है, दूसरे शब्दों में binding class बनाने की जरूरत पड़ती हैं।

🎯 निष्कर्ष तालिका:

बिंदु	IConfiguration	IOptions<T>
Strong typing	❌	✅
IntelliSense	❌	✅
Validation	❌	✅
Runtime reload support	संभव है पर complex	IOptionsMonitor<T>
Testability	कठिन	सरल
Boilerplate	कम	थोड़ा अधिक

📌 तो क्यों Microsoft ने Options Pattern को prefer किया?

क्योंकि ASP.NET Core का डिज़ाइन पूरा DI-centric और strongly typed है — और Options pattern उसे clean, scalable और maintainable बनाता है। विशेष रूप से:

• बड़ा project
• बहुत सारी config settings
• अलग-अलग environment
• testability की ज़रूरत

इन सभी में IOptions<T> pattern ही श्रेष्ठ रहता है।

🧪 Tip: कब सिर्फ IConfiguration उपयोग करना चाहिए?

स्थिति	उपयोग करें
🔹 बहुत छोटा app है	IConfiguration चल जाएगा
🔹 1-2 values ही पढ़नी हैं	["MyKey"] access सरल
🔹 One-time config access है	Binding class की ज़रूरत नहीं

👉 परंतु यदि आप config को कई बार access करते हैं, validate करना चाहते हैं, test करना चाहते हैं — तो IOptions<T> ही श्रेष्ठ है।

---

Next: ASP.NET Core में Main मेथड के रन होने पर क्या होता है?